U.S. Pat. No. 6,854,114 granted to Harlan Sexton et al is incorporated by reference herein in its entirety, as background. In this patent, Sexton describes multiple VM instances accessing a shared area. Referring to FIG. 1A attached hereto, three clients have established three sessions through a server. In session 1, a call that involves services provided by the virtual machine is currently being processed by a system thread using VM instance 1. In session 3, a call that involves services provided by the virtual machine is currently being processed by a system thread using VM instance 3. Both VM instance 1 and VM instance 3 share access to the shared state area, which in the illustrated embodiment includes data for Java class X. In session 2, no call is currently active. The call memory associated with any previous call has been discarded. Only the session memory of VM instance 2 remains allocated. Because session 2 is not currently processing a call that makes use of VM instance 2, VM instance 2 is not currently assigned to any system thread. The various VM instances instantiated within the server may actually be created and run in either separate processes, or using system threads.
VM instances of the type described above typically use a Java virtual machine interpreter (such as interpreter 110 in FIG. 1B) which is responsible for interpreting Java byte codes. FIG. 1B is described in U.S. Pat. No. 7,032,216 granted to Dmitry Nizhegorodov, which patent is hereby incorporated by reference herein in its entirety, as background. In this patent, Nizhegorodov states that, in addition to the byte codes, a native compiler produces translated code 120, which is also loaded in the virtual machine. Preferably, the translated code 120 is configured to interact with interpreter 110 to support an execution model that mixes byte-interpreted and natively compiled classes. Thus, routines in translated code 120 may call routines that are interpreted, and interpreted routines may call translated code 120 routines, thereby providing call interoperability. Virtual machine services 130 are provided for supplying such services as dynamic memory management and garbage collection. Translated code 120 is generated to use the API of virtual machine services 130 (which is used by interpreter 110) by passing the context parameter or handle to the routines of the virtual machine services 130.
Run-time environment 140 of FIG. 1B provides base functionality of the virtual machine, interfacing with the underlying operating system and relational database system. Run-time environment 140 may also include a meta-object system such as that described in U.S. Pat. No. 6,782,532 granted to Sexton, et al., which patent is also hereby incorporated by reference herein in its entirety, as background. Accordingly, translated code 120 is configured to interact with run-time environment 140 in the same way as virtual machine services 130, for example by laying out objects in the same way and using the same meta-object system.
Runtime environment 140 of the type described above is normally responsible for managing memory for objects that are created and destroyed during the execution of a program. Hence, runtime environment 140 may be built to use a memory management system that is paged, as described in U.S. Pat. No. 6,434,685 granted to Sexton, et al., which patent is hereby incorporated by reference herein in its entirety, as background. However, a paged memory is difficult to use with translated code that requires contiguous memory, as discussed next. Translated code 120 is typically produced from a number of basic blocks 211-217 (FIG. 2A) that are normally laid out contiguously one after another. The layout (FIG. 2B) is typically frozen so it can be shared among multiple users. When using a paged memory management system, translated code 120 which is larger than the size of a single page, requires allocation of contiguous pages 201-203 so as to preserve one or more control transfers 221-224. As contiguous pages 201-203 (FIG. 2C) are typically not available, their allocation for holding translated code 120 is an issue.
One technology employed by several Java Virtual Machines (JVMs) to run Java code is dynamic compilation, which is also called Just-in-Time (JIT) compilation. In such a scenario, Java bytecodes are compiled into native machine code, on demand. This allows Java bytecodes to be interpreted by the JVM until they are found to be heavily used at which time they are compiled by the JIT compiler. However, to the inventors knowledge, each instantiation of a Java application of several prior art systems runs in its own process, and as such each process has it's own copy of any native machine code which has been compiled during the course of that VM instance. While having process-private copies of compiled code is simpler, it does not scale well. To share compiled code, it can be loaded by runtime environment 140 if smaller than a page. However, compiled code is typically larger than a page and cannot be loaded, because multiple contiguous pages are not available during normal operation.